home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 8604 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.6 KB
  1. Path: newshost.lanl.gov!tanmoy
  2. From: tanmoy@qcd.lanl.gov (Tanmoy Bhattacharya)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: What is &Variable (declared as: char Variable[10])?
  5. Date: 03 Mar 1996 05:44:29 GMT
  6. Organization: Los Alamos National Laboratory
  7. Message-ID: <TANMOY.96Mar2224429@qcd.lanl.gov>
  8. References: <4gqpa1$3h9@alcor.usc.edu> <4hagqg$6je@daily-planet.execpc.com>
  9. NNTP-Posting-Host: qcd.lanl.gov
  10. Mime-Version: 1.0
  11. Content-Type: text
  12. In-reply-to: sprecher@execpc.com's message of Sat, 02 Mar 1996 23:00:52 GMT
  13.  
  14. In article <4hagqg$6je@daily-planet.execpc.com>
  15. sprecher@execpc.com (Reginald W. Sprecher) writes:
  16.  
  17. <snip>
  18. RWS: 1.  A pointer - a pointer is a variable which has as its purpose the
  19. RWS: ability to point to another variable.  One thing that needs to be made
  20. RWS: clear here is that the size of a pointer is always the same no matter
  21. RWS: what type of data the pointer is pointing at ( a pointer to a char and
  22. RWS: an int are the same size). However, this is not and will not hold
  23.  
  24. You should read the FAQ first: there is simply no point trying to
  25. `discover' the same incorrect statement over and over again. There is
  26. absolutely no requirement that pointers to different types will have
  27. the same size. There are many machines where this is not true. The FAQ
  28. gives examples.
  29.  
  30. <snip>
  31. RWS: Now lets walk through a small program.  (assume for this discussion
  32. RWS: that we are running on a 16 bit machine, aka pc-xt.
  33. RWS: 
  34. RWS: void main(void)
  35.  
  36. This statement leads to undefined behaviour. main must return int  in C.
  37.  
  38.  
  39. RWS:   a_pointer = c;       // or a_pointer = &c[0]
  40.  
  41. This is a syntax error in C.
  42.  
  43. <snip>
  44. RWS: |                |     1012        a_pointer (since we
  45. have assumed a 
  46. RWS: |                |     1013             16 bit machine a
  47. pointer lives in 2 bytes 
  48.  
  49. Not necessarily. First, a pointer may contain information in addition
  50. to the address. Second, on 16 bit word addressable machines with 8 bit
  51. chars, it might be useful to have longer pointers.
  52.  
  53. <snip>
  54. RWS: 2.  The next thing we encounter is the sizeof instructions.  Be
  55. RWS: carefull here, sizeof looks like a C runtime function, acts like a C
  56. RWS: runtime function but is not a C runtime function.  It is really some
  57.  
  58. Which runtime function can be called on a type? Which can be called
  59. without parentheses? Remember sizeof (char*) and sizeof a are both
  60. valid. 
  61.  
  62. RWS: array_name[m][n]
  63. RWS: 
  64. RWS: * ( *(array_name + (m * size_of_data_in_array) ) + (n *
  65. RWS: size_of_data_in_array) )
  66.  
  67. Careful. I think, but am not sure, that you are confused. Have you
  68. read the FAQ about the difference between char **x and char x[5][3]
  69. for example?
  70.  
  71. RWS: 1)  Using the name of an array somehow yields or calculates or
  72. RWS: generates the address.
  73. RWS: 
  74. RWS: This is not true. The name of the array is the address of the array.
  75. RWS: The operation is not a calculation or de-referencing, or ....
  76. RWS: I have personally never heard of this 'decay' process.  If you look
  77. RWS: what is really happening inside the code there is no decay process.
  78. RWS: This is because the program always reference an array by its address
  79. RWS: which is the address of the first element in the array.  This same
  80. RWS: pricincipal applies to multi-dimensional arrays as well.
  81.  
  82. And precisely this is called the `decay'. In all type compatibility
  83. statements, an array name can be used and will have the same type as a
  84. pointer to the first element. Remember &array_name is also a pointer,
  85. but is not of the same type.
  86.  
  87. RWS: 
  88. RWS: 
  89. RWS: 2)  &c is a pointer to something.
  90. RWS: 
  91. RWS: &c is by the above definition is not a pointer, it is an address, and
  92. RWS: specifically it is an address to a variable called c, which is of type
  93. RWS: char, and whose first element is at some address.
  94.  
  95. The distinction between address and a pointer you are trying to make
  96. is exactly the difference between what in C is called a pointer value
  97. and a pointer lvalue. It is like the difference between an ordinary
  98. variable of type int (say i), and a value of type int, say 5. Calling
  99. &c not a pointer goes against all established definitions of what a
  100. pointer is.
  101.  
  102. RWS: 
  103. RWS: &c is the address of myarray which is:
  104. RWS: 
  105. RWS: &c == c == &c[0] == 1008 (in our memory map)
  106.  
  107. Any conforming compiler should diagnose the expression &c == c as
  108. erroneous (when c is an array): &c and c simply do not have the same
  109. type. c == &c[0] is true because of the `decay'.
  110.  
  111. <snip>
  112. RWS: 3)  Pointer take on different sizes.
  113. RWS: 
  114. RWS: Pointers only take on a different size when going from one platform to
  115. RWS: another.  If you write a program and define 1000 pointers that can
  116. RWS: point at base data types or your own structures, the size (amount of
  117. RWS: memory) that the pointer varialbe it self consumes is still the same
  118. RWS: size.  Again, the factor here is what is the address space of your
  119. RWS: target system.
  120.  
  121. This is simply incorrect: and shows that the poster does not have a
  122. good grasp of portable C; and is too arrogant to find the correct
  123. answers that are so easily available.
  124.  
  125. RWS: 
  126. RWS: Reginald W. Sprecher
  127. RWS: A.C.M.E. Consulting
  128. RWS: Assembler, C/C++,Microprocessor,Embedded Consulting
  129. RWS: sprecher@execpc.com
  130.  
  131. I leave the signature in as I found it humorous at the end of such a
  132. completely erroneous post.
  133.  
  134. Cheers
  135. Tanmoy
  136. --
  137. tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
  138. Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
  139. Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
  140. <http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
  141. internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
  142. fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]
  143.